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Abstract 

New applications for the Internet such as video on de- 
mand, grid computing etc. depend on the availability of 
high bandwidth connections with acceptable Quality of Ser- 
vice (QoS). There appears to be, therefore, a requirement 
for a market where bandwidth-related transactions can take 
place. For this market to be effective, it must be efficient for 
both the provider (seller) and the user (buyer) of the band- 
width. This implies that: (a) the buyer must have a wide 
choice of providers that operate in a competitive environ- 
ment, (b) the seller must be assured that a QoS transaction 
will be paid by the customer, and (c) the QoS transaction 
establishment must have low overheads so that it may be 
used by individual customers without a significant burden 
to the provider. 

In order to satisfy these requirements, we propose a 
framework that allows customers to purchase bandwidth us- 
ing an open market where providers advertise links and ca- 
pacities and customers bid for these services. The model is 
close to that of a commodities market that offers both ad- 
vance bookings (futures) and a spot market. We explore the 
mechanisms that can support such a model. 



1. Introduction 

Years of research on Quality of Service (QoS) architec- 
tures for the Internet have resulted in sophisticated propos- 
als that have not been broadly exploited commercially. In 
particular, Integrated Services (IntServ) |4| and Differenti- 
ated Services (DiffServ) 1 1 1 have long been supported by 
major router and operating system vendors, yet have only 
seen minimal use in practice. One explanation offered by 
the networking and QoS community has been a lack of a 
commercialization model, together with the necessary ac- 
counting and charging architecture |7|. A related crucial 
issue is assurance of end-to-end QoS coherence in the face 
of multiple intervening parties, such as transit ISPs. 

These two issues, taken together, are responsible for sup- 



pressing interest from both the ISPs (in commercially ex- 
ploiting QoS to its full potential) and the users (in taking 
advantage of such services). Simply put, if an ISP can- 
not be paid for reserving bandwidth to a user, they will not 
offer QoS; if users cannot be assured of end-to-end QoS, 
they will not pay for the service. Compounding the prob- 
lem is the issue of management: it is certainly possible for 
a large entity, such as a multi-national company, to coor- 
dinate with the relevant ISPs so that its various geograph- 
ically dispersed networks are connected provisioned using 
a series of DiffServ or IntServ tunnels. However, the ef- 
fort is considerable and requires manual intervention from 
a number of people. Perhaps most importantly, the ISPs' 
network operations centers (NOCs) will need to configure 
the various routers appropriately. Clearly, such an approach 
will not scale well if preferentially treated bandwidth is to 
become a commodity that can be traded, as has been rec- 
ognized before 1 5 1 . Yet, the increasing use of the Internet 
for time-sensitive or otherwise critical applications effec- 
tively mandate some form of bandwidth reservation, often 
for short periods of time (e.g., watching a movie). 

We present a market-based approach to self-managing 
QoS across multiple ISPs. Our architecture introduces a 
Bandwidth Exchange (Band-X), which facilitates the trad- 
ing of reserved bandwidth between ISPs and users. This fa- 
cility allows purchasing bandwidth in advance (effectively 
creating a "futures" market for bandwidth) as well as on the 
"spot" market. Users can select from a range of offerings by 
various ISPs to create an end-to-end pipe (with the desired 
bandwidth and QoS) piece-meal, or can choose to purchase 
a complete package from a single provider (or consortium 
of providers), where available. This is similar to the way 
people purchase low-cost airplane tickets online. 

To ease the task of accounting and administration, we use 
the micropayment architecture introduced in 1 3 1 to provide 
both accounting and authorization. Briefly, users purchas- 
ing bandwidth on Band-X are provided with credentials 
that allow them to establish the necessary QoS pipes among 
the necessary network elements (routers), within the con- 
straints of their contracts. Our use of a trust-management 



system (Key Note 1 2 1) allows us to perform both billing and 
authorization with the same mechanism, simplifying the ar- 
chitecture and eliminating the need for manual configura- 
tion or universal trust of the Band-X service (e.g., to con- 
figure the relevant routers of several ISPs). 

To better illustrate the use of the Band-X architecture, 
we next describe a sample usage scenario involving an end 
user and several ISPs. In Section |2] we present the system 
architecture in more detail. Section[3]describes the various 
components of our system, in particular our micro-checks 
mechanism, and how they operate together, along with a 
security analysis. We discuss related work in Section|4] 

1.1. Motivation 

Consider the following scenario of a user Alice wish- 
ing to reserve an end-to-end 50Mbps "pipe" from Rome 
to Dublin 1 . Using an appropriate tool (e.g., auction site, 
database, service bureau) she decides to purchase a link 
from Rome to Paris offered by ISP A, and another link from 
Paris to Dublin offered by ISP B. However, Alice does not 
need the QoS pipe immediately; rather, she needs it for the 
time her remote presentation is scheduled, a few days later. 

Payment may be effected in various ways (examples 
given later in the paper) depending on the policy of each 
ISP. Once the reservation has been booked, each ISP sends 
a credential to Alice authorizing her to use the required link 
at the desired time and date and for the appropriate time in- 
terval. The credentials are set to expire at the end of the 
reserved period. Again, depending on the way payment is 
handled and the policies of the ISPs and other involved par- 
ties, more than these two credentials may be required for 
access to be granted (this is explained later). 

Just before the link needs to be established, Alice's QoS 
negotiation agent (QNA) will send a QoS request to the 
network elements (NEs) of the two ISPs to ensure that 
the appropriate resources have been allocated. Since two 
providers are involved, Alice's QNA will need to contact 
each ISP separately. Depending on the bandwidth reser- 
vation protocol used, Alice's QNA may communicate with 
a central entity within the ISP, or may negotiate a path 
through the ISP's network and then reserve the desired 
bandwidth with each network element separately. 

For this discussion, we have limited ourselves to band- 
width reservation; additional QoS requirements (such as la- 
tency) may be specified within the same framework. 
Spot Market Given an efficient purchasing mechanism, 
an "advance" booking such as the one mentioned earlier 
may be made even seconds before the channel will be used, 
so the term "spot market" is used to define a different pay- 
ment regime that may be used to sell the unused network 

1 We use geographical identifiers instead of IP addresses to simplify the 
example. 



Clearing House 




Figure 1 . The Band-X Clearing House acts as a repos- 
itory of all the offers for bandwidth issued by the ISPs. 



capacity. The "spot market" allows premium best-effort 
services to be sold. In this case, we are not making any 
promises regarding availability of bandwidth, but we say 
that by paying a small premium, packets may be treated fa- 
vorably in the allocation of the remaining bandwidth (after 
the booked commitments are served). 

2. Architecture 

2.1. Operation of the Spot Market 

Initially, the various bandwidth providers post their 
available capacities in the Band-X clearing house. The 
system can accommodate one or more such clearing houses, 
since they function as announcement boards. Apart from 
that, the clearing house is not involved in the purchase of 
bandwidth (see Figureffl. 

The postings are of the form of credentials that describe 
the identity of the ISP and promise to abide by a set of QoS 
specifications between two points of the ISPs network. The 
credential may also contain the time period that the offer 
is valid (which may be different from the expiration of the 
credential), the price of the concession, and additional ISP- 
related information, such as the path that should be taken 
between the two points. Offer credentials are signed by the 
ISP who issues them. 

Customers contact the Clearing House to collect offers 
from the ISPs. For complex paths, a customer may need to 
collect more than one offer and use them together. In an 
environment with a single clearing house, the customer can 
issue queries to get lists of offers matching his or her re- 
quirements. If there are many clearing houses, the customer 
may dispatch an intelligent agent to collect the offers and 
come back with a recommendation that meets preassigned 
constraints (price, ISP reliability etc.), query each clearing 
house independently, or use a meta-search engine. 

At the end of the search, the customer will hold one or 
more offer credentials that describe the desired path and 
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Figure 2. Customer finalizes the path selection by 
downloading the offer credentials. 




Figure 3. The customer issues a reservation request by 
sending the offer credentials collected from the Band-X 
Clearing House along with a credit-worthiness credential 
issued by his or her credit institution. 



QoS specs, as shown in Figure|2 

At this point, the customer has not actually purchased the 
bandwidth. In order to issue payment and reserve the band- 
width, a number of steps have to be taken. The customer (or 
the host at one of the end-points of the connection) contacts 
the first-hop network element (NE) and activates the reser- 
vation protocol. The NE issues a challenge which is then 
returned signed by the customer. This response also con- 
tains the offer credentials collected by the customer and a 
credit-worthiness credential issued by the customer's credit 
institution, as shown in Figure 

This exchange accomplishes the following: (a) identifies 
the customer (the key that has signed the NE challenge), (b) 
provides proof of good standing (the credential issued by 
the credit institution to the customer's key), (c) limits pay- 
ment only to the offer credentials provided, (d) can be used 
only for that particular transaction since it depends on the 
challenge issued by the NE. On the basis of this transac- 
tion, the first hop NE contacts other NEs within the ISPs 
network establishing the purchased path. If the path crosses 
ISP boundaries, additional transactions have to be carried 
out between the NE of the new ISP and the end user, as 




Figure 4. Each time the path crosses ISP boundaries, 
additional negotiations have to be carried out, to ensure 
that the next-hop ISP can be paid for passage. 




Figure 5. The path has now been established and com- 
munication can proceed. 



shown in Figure 0] 

When the last hop is reached, the connection is consid- 
ered established and the final destination host can initiate a 
connection with the customer's host over the reserved path 
(Figure|5}. 

There is no need for the ISPs offers to match exactly 
the requirements of the customer. For example, if Alice 
requires a 50Mbps link from Atlanta to Dublin, she may 
use an offer for a 100Mbps connection, but purchase only 
50Mbps. The providers may include clauses in their offer 
credentials allowing or prohibiting such un-bundling. The 
flexibility of the policy language used in Band-X allows 
many such special considerations to be encoded within the 
offer credentials. The advantage of having these restrictions 
expressed as policy is that they can be used directly by the 
ISP's infrastructure without any need for conversion. More- 
over, the customer cannot alter these restrictions since they 
are an integral part of the credential (and are protected by 
the ISP's signing of the offer credentials). 



2.2. Operation of the Futures Market 

In the Spot Market, the customer collects the offers and 
sets up the path in short order, because the offers are effec- 
tive immediately and have a short lifetime. There is no need 
to negotiate with the ISPs before the reservation. 

In the Futures Market the situation is different, since the 
ISPs need to know what bandwidth has been purchased to 
plan their resource allocation. Once the customer collects 
the offers, a notional reservation negotiation will be initi- 
ated. The negotiation is notional because no state changes 
are actually effected on the network elements. The cus- 
tomer's QNA will not detect any change in the negotiation. 
Within the ISPs network, no path is created; rather the reser- 
vation is entered in the ISP's database, and a reservation 
credential is sent to the end user. This credential will then 
be used in the same manner as the offer credential was used 
in the Spot Market scenario. Since the bandwidth has been 
paid for, the reservation credential commits the ISPs to pro- 
vide the requested resources at the appropriate future time. 

At that time (when the path is actually required) the cus- 
tomer initiates a reservation negotiation, but sends only the 
reservation credential (instead of the offer and credit insti- 
tution credentials). The ISP network elements will reserve 
the path as specified in the reservation credential. The case 
of multiple ISPs is handled in a similar manner. 

2.3. Role of the Credit Institution 

Like the Clearing House, there is no requirement to have 
a single Credit Institution. It is, however, important that 
the ISPs have a way of confirming the keys of the various 
Credit Institutions. This is because the credit-worthiness 
credentials (CWCs) issued by the Credit Institutions to their 
customers will have to be verified by each ISP. If an ISP 
cannot verify a CWC, then it may be fake; trusting it may 
result in the equivalent of a bounced check. 

3. Implementation 

3.1. KeyNote Microchecks 

The micro-payments system introduced in 1 3 1 forms the 
basis of our approach. The general architecture of this 
micro-billing system is shown in Figure [6] Under Band- 
X, a Merchant is an ISP selling bandwidth and a Payer is a 
client wishing to make a QoS reservation. 

In this system, Provisioning issues KeyNote 1 2 1 creden- 
tials to users (Payers) and ISPs (Merchants). These creden- 
tials describe the conditions under which a user is allowed 
to perform a transaction (i.e., the user's credit limit) and the 
fact that a Merchant is authorized to participate in a partic- 
ular transaction. 




Figure 6. Microbilling architecture diagram. We have 
the generic terms for each component, and in parenthe- 
ses the corresponding players in Band-X. The arrows 
represent communication between the two parties: Pro- 
visioning issues credentials to Payers and Merchants; 
these communicate to complete transactions; Merchants 
send transaction information to Clearing which verifies 
the transaction and posts the necessary credits/charges 
or arranges money transfers. Provisioning and Clearing 
exchange information on the status of Payer and Mer- 
chant accounts. 



Initially, the ISP encodes the details of the available 
bandwidth into an offer which is uploaded to the Band- 
X site, along with a credential that authorizing any user to 
utilize the bandwidth under the same conditions as those 
enclosed in the offer. Once the user finds an offer (and as- 
sociated credential) that is acceptable, she must issue to the 
ISP a microcheck for this offer. The microchecks are en- 
coded as KeyNote credentials that authorize payment for a 
specific transaction. The user creates a KeyNote credential 
signed with her public key and sends it, along with her cre- 
dential from Provisioning, to the first network element of 
the ISP. This credential is effectively a check signed by the 
user (the Authorizer) and payable to the ISP (the Licensee). 
The conditions under which this check is valid match the 
offer sent to the user by the ISP. Part of the offer is a nonce, 
which maps payments to specific transactions, and prevents 
double-depositing of microchecks by the ISP. 

To determine whether he can expect to be paid (and 
therefore whether to accept the payment), the ISP passes 
the action description (the attributes and values in the offer) 
and the user's key along with the ISP's policy (that iden- 
tifies the Provisioning key), the user credential (signed by 
Band-X ), the offer credential (signed by the ISP), and 
the microchecks credential (signed by the user) to his local 
KeyNote compliance checker. If the compliance checker 
authorizes the transaction, the ISP is guaranteed that Pro- 
visioning will allow payment. The correct linkage among 



Keynote-Version: 2 
Local-Constants : 

ISP.KEY = "rsa-base64 : 7231f . . . " 
Authorizer: ISP.KEY 
Licensees : 

Conditions: app_domain == "Band-X" && 
currency == "USD" && 
Sbandwidth <= "50Mbps" && 
link_name == "Dublin-NYC" && 
Saraount >= 3.00 

&& date < "20031120 -> "true"; 
Signature : "sig-rsa-shal-base64 : ablXXA. . . " 



the Merchant's policy, the Provisioning key, the user key, 
and the transaction details follow from KeyNote's seman- 
tics 1 2 1 . If the transaction is approved, the ISP can configure 
the appropriate routers such that the user's traffic is treated 
according to the offer, and store a copy of the microcheck 
along with the user credential and associated offer details 
for later settlement and payment. 

Periodically, the ISP will 'deposit' the microchecks (and 
associated transaction details) he has collected to the Clear- 
ing and Settlement Center (CSC). The CSC may or may 
not be run by the same company as the Provisioning, but it 
must have the proper authorization to transmit billing and 
payment records to the Provisioning for the customers. The 
CSC receives payment records from the various ISPs; these 
records consist of the offer, and the KeyNote microcheck 
and credential from the user sent in response to the offer. 
In order to verify that a microcheck is good, the CSC goes 
through a similar procedure as the ISP did when accepting 
the microcheck. If the KeyNote compliance checker ap- 
proves, the check is accepted. Using her public key as an 
index, the user's account is debited for the amount of the 
transaction. Similarly, the ISP's account is credited for the 
same amount. 

3.2. Band-X Operation 

Having seen the overall system architecture, let us look 
at a particular example. Alice is a user who wants to reserve 
some bandwidth for a particular link with Nick's ISP. Every 
evening Alice contacts her banker and obtains a fresh Check 
Guarantor credential, which allows her to issue KeyNote 
microchecks. The CG credential (most of the hex digits 
from the keys have been removed for brevity) allows Alice 
to write checks for up to 5 US Dollars, and she can do so 
until March 24th, 2004. 



Keynote-Version: 2 
Local-Constants : 

ALICE.KEY = "rsa-base64 :MCgCIQ. . . 

CG_KEY = "rsa-base64 :MIGJAo . . . " 
Authorizer: CG_KEY 
Licensees: ALICE_KEY 

Conditions: app.domain == "Band-X" && 

currency == "USD" && Samount < 5.01 
&& date < "20040324" -> "true"; 

Signature: "sig-rsa-shal-base64 : QU6SZ . . . " 



Alice now wants to reserve some bandwidth to Dublin. 
She searches the Band-X for a suitable offer, and locates 
one issued by Nick's ISP that contains the following Offer 
credential, indicating that she could purchase 50Mbps on 
the specific link ("Dublin-NYC") for 3 US dollars: 



Alice then writes a check for the appropriate amount: 



The nonce is a random number that must be different 
for each check, guaranteeing that there will be no double- 
depositing of checks. Alice then sends the Offer credential 
and the micro-check to Nick's router using a protocol such 
as RSVP Nick receives these credentials, validates the mi- 
crocheck to make sure that he will get paid, and configures 
the router appropriately. If the check is not good, Nick will 
say so, and refuse to accept the file. Nick will verify that he 
will get paid, and will evaluate the Offer credential and the 
microcheck using a simple policy such as: 



Keynote-Version: 2 
Local-Constants : 

NICK.KEY = "rsa-base64 : 7231f . . . " 

CG.KEY = "rsa-base64 :MIGJAo . . . " 
Authorizer: POLICY 
Licensees: CG_KEY && NICK.KEY 
Conditions : 

app_domain == "BAND-X" -> "true"; 



This policy says that anything that Nick's key and the 
Check Guarantor's key jointly authorize is allowed. Thus, 
Alice must submit a valid payment and a valid Offer cre- 
dential. Since the bandwidth was paid for, and a path can be 
found from POLICY to a user (Alice) that has delegated to 
Nick's key, which in turn has created an open-access Offer 
credential, the operation is allowed. As a matter of business 
practice, Nick may require periodic payments from Alice in 



Keynote-Version: 2 
Local-Constants : 

ALICE.KEY = "rsa-base64 :Mcg. . . " 

ISP.KEY = "rsa-base64 : 7231f . . . " 
Authorizer: ALICE.KEY 
Licensees: ISP.KEY 

Conditions: app_domain == "BAND-X" && 

currency == "USD" && amount == "4.25" 
&& nonce == "eb2c3df c8e9a" && 
date == "20041120" -> "true"; 

Signature: "sig-rsa-shal-base64:Qsd. . ." 



order to keep the bandwidth reserved. Alice must know that 
and send microchecks at the appropriate intervals. 

If additional routers need to be configured in Nick's ISP, 
the first router forwards the necessary information to the 
next. Note that it is not necessary for the router itself to 
perform the signature verifications and policy validations: it 
can simply refer these operations to a Policy Decision Point 
(PDP), as is envisioned by the IntServ architecture. 

3.3. Security Analysis 

Similar to |3| and |12|, our system has three types of 
communication: provisioning, reconciliation, and transac- 
tion. Although delegation of credentials (and thus access 
rights to reserved bandwidth) is possible, we do not con- 
sider it in this paper. We shall not worry about any value 
transfers to banks, as there already exist well-established 
systems for handling those. All communications between 
Band-X, ISPs, and users can be protected with existing 
protocols such as IPsec or TLS. This covers both provision- 
ing and reconciliation, which occur off-line from the actual 
bandwidth reservation and use. Furthermore, the transac- 
tions themselves (establishing the QoS pipes, or the right 
to use existing pipes) can be protected through the same 
means; the only requirement is that the user can authenti- 
cate with each ISP. 

The confidentiality of the transmitted data itself is not 
within the purview of our system, nor is it a responsibility of 
the ISP; if the users do not trust the network with respect to 
data confidentiality or integrity, they should use end-to-end 
security protocols, e.g., IPsec or TLS. We do not impose any 
limitations that would preclude the use of these protocols. 

The user needs to ensure that the ISPs provide the 
promised service. This can be easily verified by the user 
using a number of existing protocols and tools. Protect- 
ing against over-charging ISPs is also straightforward: the 
details of each transaction can be verified at any point in 
time, by verifying the credentials and the offer. Since only 
the user can create microchecks, a dispute claim can be re- 
solved by "running" the transaction again. Thus, the user 
is safe even from a collusion between any number of ISPs 
and the Band-X service. The ISP must ensure that they 
are paid for the services offered. Since it has a copy of all 
transactions (the Band-X credential, the microcheck, and 
the offer), it can prove to the Band-X, or any other party, 
that a transaction was in fact performed. 

The Band-X also needs to be paid for the services of- 
fered. Since the Band-X does the clearing of the mi- 
crochecks, the ISP has to provide the transaction logs to the 
Band-X. The Band-X can then verify that a transaction 
was done, and at what value. A collusion between the ISP 
and a user is somewhat self-contradicting: the user's goal is 
to minimize cost, while the ISP's is to maximize revenue, 



each at the expense of the other. The function of the Band- 
X is to verify each transaction (perhaps sampling, for very 
large numbers of transactions), debit the ISP and credit the 
user (presumably keeping some commission or small fee in 
the process): if the ISP does not give any credentials to the 
Band-X, then no work was done as far as the Band-X is 
concerned (and no payments are made, which benefits the 
user); claiming more transactions than really happened is 
not in the best interest of the user (so no collaboration could 
be expected in the direction), and the ISP cannot "fabricate" 
transactions. Since value is not stored in either the ISP or 
the user, only a reliable log of the transactions is needed at 
the ISP (and, optionally, at the user). 

4. Related Work 

Despite the ever increasing use of time-sensitive proto- 
cols {e.g., VoIP, audio on demand, etc.) bandwidth reser- 
vation has not been particularly successful. This is caused 
mainly by the fear that since these applications have modest 
bandwidth requirements the operation of a reservation and 
payment infrastructure would not be feasible economically. 
Recently, however, newer applications such as video on de- 
mand, tele-presence, and Grid Computing, have bandwidth 
requirements that may constitute a significant portion of the 
available bandwidth. In such cases the overheads associated 
with the reservation and billing are smaller (because we are 
dealing with fewer more expensive reservations), while the 
benefits are greater because of the impact of the data flows 
on the infrastructure. 

In Grid Computing in particular, efforts are already un- 
derway 1101 . to allow end-users to create end-to-end light 
paths (optical links that allow unstructured access to the 
fiber infrastructure) by combining individual segments very 
much as we described in the introduction. The current sys- 
tems, however, are targeted towards the academic commu- 
nity and hence assume that end-users have the required ex- 
pertise and have non-competitive usage strategies. Specif- 
ically under the "User Controlled Light Paths" framework 
1101 . (a) end-users have to be known by the system in ad- 
vance, (b) policy enforcement is not addressed, (c) there is 
no purchasing of bandwidth, since the network is consid- 
ered a common resource. In a commercial environment, a 
similar system must deal with billing {i.e., how the reserved 
bandwidth can be paid by the user) and must support band- 
width reservation in a scalable and secure manner. 
Billing Internet telephony (or voice over IP) is widely 
considered to be the "killer" application that will convince 
users that they need QoS (and the higher prices this im- 
plies). This is underlined by the fact that the literature con- 
centrates on QoS for VoIP applications. Systems such as 
OSP 1 9 1 provide a way for large organizations to settle pay- 
ments related to VoIP call clearing. Although OSP is very 



close to Band-X, it does not involve the end-user, but in- 
stead concentrates on the ISPs. For example OSP only ex- 
changes Call Detail Records, the ISPs are responsible for 
handling customer billing and payment. In other words the 
model is that of the traditional TELCO whereby payment 
is handled either via prepaid cards, or monthly telephone 
bills. Band-X is not bound to a particular signaling mech- 
anism (such as H.323) and provides far greater flexibility in 
that users that have no prior relationship with an ISP can 
use the reservation protocol and pay for their bandwidth. 
Although many papers have been written on market-based 
routing, these are concerned with the use of market-based 
techniques in routers, ignoring the problems of accounting, 
billing and payment. Band-X can use any router that sup- 
ports a reservation protocol (and the Band-X extensions). 
Secure QoS Reservations A secure reservation protocol 
is required to provide a number of assurances including (a) 
that only authorized users can make reservations, (b) that a 
reservation made by a user can be traced back to that user, 
and (c) that users cannot make reservations over their al- 
located quota. These are to protect against starvation or, 
perhaps even worse, denial of service that can occur when 
multiple unauthorized requests result in the allocation of all 
available bandwidth thus preventing legitimate users from 
reserving bandwidth. The above considerations imply some 
authentication mechanism and the use of integrity checks 
on the transmitted data. OSP runs over TLS which en- 
crypts the exchanged data. X.509 certificates are used to 
authenticate both ends of a transaction. However, this se- 
cure communication is used only for the data exchange be- 
tween the ISP nodes running OSP. Customer identification 
is still handled via a separate system that is operated by the 
ISPs and usually involves some kind of PIN or password 
authentication. In 1 8 1 the actual charging is delegated to a 
"payment-agent" that is assumed to run on the same ma- 
chine as the user. However, no details are provided on how 
the "payment-agent" effects payment. 

All the systems we have looked at assume that the user 
trusts some provider who determines the cost of the con- 
nection. No system tries to empower the user by providing 
choice. Band-X allows the user to select the best (as de- 
fined by the user) providers to handle the connection and 
makes sure that at the end of the day everybody gets paid. 
This approach is far superior to the piecemeal approaches 
found in the literature. 

Scalability Each reservation carries with it some over- 
head. This includes both protocol overhead, but also state 
that must be maintained by routers for each reservation. As 
the number of reservations increases so does the overhead. 
Unless there is some kind of aggregation of requests this 
overhead will ultimately define an upper bound on the num- 
ber of reservations that can be accommodated by the exist- 
ing infrastructure. The complexity of some of the proposed 



systems (e.g., [ 14 1, and 1 8 1) and the small scale of their test- 
beds (e.g., 200 nodes in II II ) casts grave doubts on their 
ability to scale to millions of users and thousands of net- 
work elements. Various techniques that attempt to improve 
scalability through aggregation are vulnerable to abuse. For 
example, in 1151 the authors describe request aggregation 
whereby multiple requests are merged into a single larger 
request for the total bandwidth asked for by the individ- 
ual requests. This approach, however, may result in an up- 
stream node declining the single request thus denying ac- 
cess to all the requests, even through some of the individual 
requests could have gone through 111 31 . 

Since Band-X covers both reservation and payment, the 
problem of scalability has to be addressed in both areas. As 
far as reservation is concerned, Band-X uses the RSVP 
protocol and so can take advantage of the optimizations and 
efficiencies that have either been integrated, or are being 
considered for inclusion into the protocol. In the area of 
billing, the use of the Keynote-based micro-payment archi- 
tecture has been shown to scale well 1 3 1. 

5. Summary and Concluding Remarks 

To minimize network congestion which can cause com- 
plaints and dissatisfaction among users, ISPs overprovision 
their networks |6). Unfortunately, unused bandwidth is 
wasted since it cannot be saved for later use. While band- 
width remains cheap, the ISPs can continue to add capac- 
ity ahead of the actual demand, but this state of affairs will 
only last as long as users of time-sensitive services prefer 
the telephony network. The enormous cost difference be- 
tween the telephony network and the Internet provides an 
implicit subsidy. However, as users switch to the Inter- 
net for their time-sensitive services, ISPs will no longer be 
able to expand their networks. We believe that the frame- 
work described in this paper offers a migration path for both 
users and ISPs through the creation of an open market for 
bandwidth over the Internet. The reason is that the Band- 
X framework supports a competitive market offering trans- 
parency, and security. At the same time the low overheads 
of the Band-X framework ensure scalability through the 
use of a micro-payment environment. 

The benefits offered by Band-X include: (a) "instant" 
purchases of bandwidth and advanced purchases allowing 
the ISPs to plan ahead their resource allocation strategies, 
while being able to auction off unused capacity rather that 
letting it go at Best-Effort prices, (b) efficiency, requiring 
only a few exchanges between a buyer and sellers to ef- 
fect a reservation. Moreover, the use of the Keynote-based 
micro-payment framework provides system-wide efficiency 
and scalability, (c) compatibility with existing standards: by 
utilizing an existing reservation protocol (RSVP), a Band- 
X system may be be deployed with minimum disruption. 



(d) trades between parties that have no established business 
relationships: The Credit Institution(s) link buyers and sell- 
ers, thus allowing a transaction to go through without the 
need for a buyer to be known to the seller. This is a key re- 
quirement for the bandwidth market to work freely with the 
buyer being able to select the seller offering the best value 
for money, (e) openness: the Band-X model allows the 
presence of multiple entities for each role (i.e., we can have 
multiple Credit Institutions, Clearing Houses, buyers and 
sellers) operating within a single market. This increases the 
competition and overall reliability of the entire system. 
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